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DETAILED ACTION 

Response to Arguments 

1 . Applicant's arguments filed 3/3/10 have been fully considered but they are not 
persuasive. 

Regarding "priority", the applicant argued that, ". . .the features recited in pending 
claims are fully supported in the provision application. . .the applicant request that the examiner 
defer determining whether claims are adequately supported by provision application. . .until time 
of allowance..." in page 34-35. 

In response to applicant's argument, the examiner respectfully disagrees with the 
application argument that "the features recited in pending claims are fully supported in the 
provision application" since application fails to provide facts (i.e. specifically recite where in the 
provisional application provide adequate support for these pending claim). By merely arguing 
without providing the supporting fact is clearly and error. However, examiner acknowledges 
applicant requests to defer the issue until time of allowance. Thus, the priority issue is sustained 
in the action. 

Regarding "specification objection", the applicant argued that, ". . .applicant amends 
the specification. . .to address the concerns raised by the office action..." in page 35. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above since applicant fails to address the second issue based on lack of antecedent 
basis for claim 39 recited on the top of page 5. Thus, the specification objection is sustained. 
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Regarding obvious type double patenting rejection, the applicant argued that, 

". . .application submit a terminal disclaim to Hall to overcome the non-statutory obviousness- 
type double patenting rejection. . ." in page 36. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument since the terminal disclaimer is to Hall is improper since an attorney or agent, not of 
record, is not authorized to sign a terminal disclaimer in the capacity as an attorney or agent 
acting in a representative capacity as provided by 37 CFR 1.34 (a). See 37 CFR 1.321(b) and/or 
(c). 

Regarding claims 39, 42-50, 55-65, the applicant argued that, ". . applicant transverse 
the rejection. . . .applicant amend claims 39, 42-50, 55-65 to address the statutory subject matter 
concerns..." in page 36. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

The claim is amended to include "A tangible computer-readable medium" is into the 
preamble. "A tangible computer readable medium" is "physical/real/tangible" transitory 
transmission medium/media where the signal is traversed. Thus, claim 39 is still ineligible for 
patent protection as failing to be limited to embodiments which fall within a statutory category. 
Thus, the rejection on this count is also sustained. 

Regarding claims 1-10, 12-29, 31-39, 42-50, 54-56, 58-65, the applicant argued that, 
". . .independent claim 1 ...the combination of Buyukkoc in view of Gai does not disclose or 
suggest that "one or more of policy feature. ...requested bandwidth" . . .pending claims are 
patentable over Buyukkoc and Gai when considered alone or in any reasonable combination, for 



Application/Control Number: 09/766,943 Page 4 

Art Unit: 2463 

at least reasons given above with respect to claim 1 . . .independent claim 14 and 39 are amended 
to recite features similar to feature described above with respect to claim 1 . Therefore, applicants 
submit claims 14 and 19 are patentable over Buyukkoc and Gai... Smith does not disclose that 
"one or more of policy feature. ...requested bandwidth" . . .dependent claims that depend from 
claim 14 and 39, and therefore patentable over Buyukkoc, Gai and Smith" in pages 36-72. 

In response to applicant's argument, the examiner respectfully disagrees with 
argument above. 

Regarding claim 1, in response to applicant's arguments against the references 
individually, one cannot show nonobviousness by attacking references individually where the 
rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 
USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In 
this case, the rejection is based on the combination of Buyukkoc and Gai as set forth in detailed 
below. 

Buyukkoc discloses where one ore more policy features, identified by the policy for the 
calling party, comprises an aggregated bandwidth limit feature (see col. 17, line 30-40; see col. 
13, line 45-47; total bandwidth) and wherein the determining whether a policy condition 
associated with each policy feature is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 
1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; 
determines/decides whether rule/policy condition/state (e.g. yellow, Red, and green), 
associated/related with connectively information, threshold, quality of service, capacity, or status 
of loading/congestion, identified/recognized by the rule/policy associated with a call/connection 
for the user/subscriber is met/fulfilled according to a new call/connection (i.e. 
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load/congestion/priority /bandwidth/routes/quality-of-service states/conditions) comprises: 
calculating bandwidth for the signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 
1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; 
Table VII, VIII; determining/calculating threshold capacity/bandwidth/Gbps of the requested 
new call/connection), determining whether calculated bandwidth exceeds a requested bandwidth 
(see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 14, line 10-7 to col. 18, line 45; see 
col. 19, line 25- to see col. 21, line 30; Table VII, VIII; determining/calculating the 
determined/calculated threshold capacity/bandwidth/Gbps with threshold 

capacity/bandwidth/Gbps is higher/exceed the requested/required capacity/bandwidth/Gbps), and 
determining that the condition is satisfied for the aggregate bandwidth limit feature when the 
calculated bandwidth is determined to not exceed the requested bandwidth (see col. 14, line 10-7 
to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table VII, VIII; ; determining that 
the condition/status (i.e. red/yellow) for the total bandwidth feature when the 
determined/calculated threshold capacity/bandwidth/Gbps is not higher/exceed the 
required/requested capacity/bandwidth/Gbps). 

Gai discloses an aggregated bandwidth limit feature (see col. 4, line 50 to col. 5, line 20; 
combined bandwidth processing) and wherein the determining whether a policy condition 
associated with each policy feature is satisfied (see FIG. 4, determining if a policy 
condition/status related/associated with each policy/rule feature identified/recognized by the 
policy/rule for the caller/user is accepted/satisfied; see col. 13, line 60 and col. 18, line 65) 
comprises : calculating bandwidth for the signaling message (see col. 4, line 50 to col. 5, line 20; 
see col. 14, line 1-25; see col. 18, line 45-65; computing/calculating bandwidth for the 
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demand/request message/data) determining whether calculated bandwidth exceeds a requested 
bandwidth (see col. 4, line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; 
determining/checking whether calculated/determined bandwidth exceed the SLA bandwidth), 
and determining that the condition is satisfied for the aggregate bandwidth limit feature when the 
calculated bandwidth is determined to not exceed the requested bandwidth (see col. 4, line 50 to 
col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking whether 
traffic condition is met/accepted for the combined bandwidth processing when the 
calculated/determined bandwidth is not exceed the request bandwidth (i.e. bandwith within 
SLA). 

Regarding claims 14 and 39, in response to applicant's arguments against the 
references individually, one cannot show nonobviousness by attacking references individually 
where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 
208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 
1986). In this case, the rejection is based on the combination of Buyukkoc, Gai and Smith as set 
forth in detailed below. 

Buyukkoc discloses one ore more policy features, identified by the policy for the calling 
party, comprises an aggregated bandwidth limit feature for a particular network port by said 
calling party (see col. 17, line 30-40; see col. 13, line 45-47; total bandwidth; (see FIG. 9, 
physical trunk/port 932; see col. 20, line 1-10; col. 17, line 30-40; see col. 13, line 45-47; total 
bandwidth for the port/link) Where, when determining whether a policy condition associated 
with each policy feature is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 
13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; 
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determines/decides whether rule/policy condition/state (e.g. yellow, Red, and green), 
associated/related with connectively information, threshold, quality of service, capacity, or status 
of loading/congestion, identified/recognized by the rule/policy associated with a call/connection 
for the user/subscriber is met/fulfilled according to a new call/connection (i.e. 
load/congestion/priority /bandwidth/routes/quality-of-service states/conditions) the policy server 
is to: calculate bandwidth for the signaling message (see FIG. 8, step 840; see FIG. 10, steps 
1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 
19-30; Table VII, VIII; determining/calculating threshold capacity/bandwidth/Gbps of the 
requested new call/connection), determine whether calculated bandwidth exceeds a requested 
bandwidth (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 14, line 10-7 to col. 18, 
line 45; see col. 19, line 25- to see col. 21, line 30; Table VII, VIII; determining/calculating the 
determined/calculated threshold capacity/bandwidth/Gbps with threshold 

capacity/bandwidth/Gbps is higher/exceed the requested/required capacity/bandwidth/Gbps), and 
determine that the condition is satisfied for the aggregate bandwidth limit feature when the 
calculated bandwidth is determined to not exceed the requested bandwidth (see col. 14, line 10-7 
to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table VII, VIII; ; determining that 
the condition/status (i.e. red/yellow) for the total bandwidth feature when the 
determined/calculated threshold capacity/bandwidth/Gbps is not higher/exceed the 
required/requested capacity/bandwidth/Gbps). 

Gai discloses an aggregated bandwidth limit feature (see col. 4, line 50 to col. 5, line 20; 
combined bandwidth processing) and wherein the determining whether a policy condition 
associated with each policy feature is satisfied (see FIG. 4, determining if a policy 
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condition/status related/associated with each policy/rule feature identified/recognized by the 
policy/rule for the caller/user is accepted/satisfied; see col. 13, line 60 and col. 18, line 65) 
comprises : calculating bandwidth for the signaling message (see col. 4, line 50 to col. 5, line 20; 
see col. 14, line 1-25; see col. 18, line 45-65; computing/calculating bandwidth for the 
demand/request message/data) determining whether calculated bandwidth exceeds a requested 
bandwidth (see col. 4, line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; 
determining/checking whether calculated/determined bandwidth exceed the SLA bandwidth), 
and determining that the condition is satisfied for the aggregate bandwidth limit feature when the 
calculated bandwidth is determined to not exceed the requested bandwidth (see col. 4, line 50 to 
col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking whether 
traffic condition is met/accepted for the combined bandwidth processing when the 
calculated/determined bandwidth is not exceed the request bandwidth (i.e. bandwith within 
SLA). 

Smith discloses determining the maximum bandwidth allowable for a particular port 
authorized for use by said party (see FIG. 1-2; see col. 9, line 5-45, and abstract; determining 
predetermined/allowable/authorized bandwidth for a particular port/connection of end station). 

In response to applicant's argument, the examiner respectfully disagrees that the 
dependent claims are patentable. Since the independent claim 1 is clearly disclosed by the 
combined system of Buyukkoc and Gai and independent claim 14 and 39 are disclosed by the 
combined system of Buyukkoc, Gai and Smith, the dependent claims are also rejected for the 
same reason. 
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Terminal Disclaimer 

2. The terminal disclaimer filed on 2/3/10 disclaiming the terminal portion of any patent 
granted on this application which would extend beyond the expiration date of U.S. Patent 
7,283,512 has been reviewed and is NOT accepted. 

An attorney or agent, not of record, is not authorized to sign a terminal disclaimer in the 
capacity as an attorney or agent acting in a representative capacity as provided by 37 CFR 1 .34 
(a). See 37 CFR 1.321(b) and/or (c). 

Priority 

3. Applicant's claim for the benefit of a prior-filed application under 35 U.S.C. 1 19(e) or 
under 35 U.S.C. 120, 121, or 365(c) is acknowledged. Applicant has not complied with one or 
more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 1 19(e) as 
follows: 

The later- filed application must be an application for a patent for an invention which is 
also disclosed in the prior application (the parent or original nonprovisional application or 
provisional application). The disclosure of the invention in the parent application and in the later- 
filed application must be sufficient to comply with the requirements of the first paragraph of 35 
U.S.C. 112. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 
USPQ2d 1077 (Fed. Cir. 1994). 

The disclosure of the prior-filed application, provisional Application No. 60/176,928, 
fails to provide adequate support or enablement in the manner provided by the first paragraph of 
35 U.S.C. 1 12 for claims 1-39, 42-50, 54-65 of this application. The disclosure of the prior-filed 
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application, provisional Application No. 60/176,928 series of feature requirement for Multiple 
Service Control Point (MSCP) system where 

• the first document FAST MSCP feature requirement specification Re. 3.2 discloses 
authorization, data elements, activation, invocation, normal processing, reporting 
requirements and feature interactions, 

• the second document discloses transaction detail records Rel 3.2.0, 

• the third document disclose data schema requirement for call processing control Rel. 3.2, , 

• the fourth document discloses service administration interface Rel. 3.2, 

• fifth document discloses message and parameter specification Rel. 3.0.6 

• Sixth document discloses call flows Rel. 3.0, 

• Seventh document discloses network management requirement Rel. 3.0 

• eighth document discloses voice and telephony over ATM IWF 

• Ninth document discloses frame rely customer PVC reconfiguration 

• Tenth document discloses ATM signaling intercept processor with the GUI user guide to 
MCI WorldCOM computer system. 

These documents in provisional Application No. 60/176,928, mainly discloses generic 
specification of MSCP system that may relate to the field of invention, but there is no specific 
disclosure or clear evidence in these documents, "individually or in-combination", that provide 
adequately support or enablement in the manner provided by the first paragraph of 35 U.S. C. 112 
for the claims 1-39, 42-50, 54-65 of this instant application. 

If applicant were to disagree, it is suggest providing each document name, number, page 
number and paragraph number of the document with the corresponding claim number. 
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Specification 

4. The specification is objected to as failing to provide proper antecedent basis for the 
claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o). Correction of the 
following is required: Claim 39 recites, "a computer readable medium" in line 1. However, the 
specification fails to provide intrinsic definition/embodiment of what a computer readable 
medium is. 

No new matter must be entered. 



Double Patenting 

The nonstatutory double patenting rejection is based on a judicially created doctrine 
grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or 
improper timewise extension of the "right to exclude" granted by a patent and to prevent possible 
harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection 
is appropriate where the conflicting claims are not identical, but at least one examined 
application claim is not patentably distinct from the reference claim(s) because the examined 
application claim is either anticipated by, or would have been obvious over, the reference 
claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re 
Goodman, 1 1 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 
USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re 
Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 
USPQ 644 (CCPA 1969). 

A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may 
be used to overcome an actual or provisional rejection based on a nonstatutory double patenting 
ground provided the conflicting application or patent either is shown to be commonly owned 
with this application, or claims an invention made as a result of activities undertaken within the 
scope of a joint research agreement. 

Effective January 1, 1994, a registered attorney or agent of record may sign a terminal 
disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 
3.73(b). 
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5. Claim 14 is rejected on the ground of nonstatutory obviousness-type double patenting as 
being unpatentable over claims 1-4 of U.S. Patent No. 7,283,512 (hereinafter refers to as 
Hall' 5 12) in view of Buyukkoc. 

Although the conflicting claims are not identical, they are not patentably distinct from 
each other because claim 14 of the instant application is the same scope of the claims 1-4 of the 
Patent by adding the well-known elements and functions as set forth below. 

Regarding claim 14 of the instant application, Hall'512 discloses Asynchronous 
Transfer Mode (ATM) network for effectuating intelligent policy features with respect to a call 
to be established between two parties via a virtual channel connection a calling party and a called 
party (see claim 1), comprising: 

an ATM switch serving a customer premises equipment (CPE) operated by a the calling 
party (see claim 1); 

a signaling intercept processor associated with said ATM switch the signaling intercept 
processor to for intercepting intercept a signaling message relative to said call (see claim 1); and 

a policy server associated with said signaling intercept processor, the policy profile 
database storing entries that relate subscribers to policies, where each policy identifies one or 
more policy features, a plurality of policy features, with which the related subscriber is 
associated with a subscriber (see claim 1, 2), wherein where the policy server is to: 

determine that a policy in the policy profile database is to be enforced for the calling 
party (see claim 1-4), 

execute appropriate service logic for each policy feature of the one or more policy 
features identified by the policy for the calling party (see claim 1-4), and 
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determine whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied with respect to the 
signaling message, a connection path being established when the policy condition for each policy 
feature, of the one or more policy features identified by the policy for the calling party, is 
determined to be satisfied (see claim 1-4). 

Hall' 5 12 does not explicitly disclose "the policy server being associated with a policy 
profile database " and "where one ore more policy features, identified by the policy for the 
calling party, comprises an aggregated bandwidth limit feature, wherein the determining 
whether a policy condition associated with each policy feature is satisfied, comprises: 
calculating bandwidth for the signaling message, determining whether calculated bandwidth 
exceeds a requested bandwidth, determining that the condition is satisfied for the aggregate 
bandwidth limit feature when the calculated bandwidth is determined to not exceed the requested 
bandwidth. " 

However, Buyukkoc discloses an Asynchronous Transfer Mode (ATM) network (see 
FIG. 7-9, ATM network; see col. 19, line 55-60) for effectuating intelligent policy features with 
respect to a call to be established between a calling party and a called party (see FIG. 9, a 
connection user 904 and 902; see col. 19, line 61 to col. 20, line 24), comprising: 

an ATM switch (see FIG. 9, ATM switch 922) serving a customer premises equipment 
(CPE) operated by the calling party (see FIG. 9, CPE User 902 connects TDM switch 912; see 
col. 19, line 64 to col. 20, line 25); 

a signaling intercept processor (see FIG. 7, Regional RSD server, RRSD, 740; see col. 
13, line 22-46) associated with said ATM switch, the signaling intercept processor to intercept a 
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signaling message relative to said call (see col. 47 to col. 14, line 5; see FIG. 8, step 820; see col. 
19, line 25-30; edge node send a call query/message to RSD, thus RSD intercept/capture the call 
query/message; also see FIG. 10, step 1035); 

a policy server (see FIG. 7, central RDS server 730, i.e., Signaling Control Point, SCP) 
associated with said signaling intercept processor, the policy server being associated with a 
policy profile database (Tables VII-IX, RSD associated with a database), the policy profile 
database storing entries that relate subscriber to policies (see col. 14, line 9 to col. 15, line 50; see 
col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD stores contents 
consists call/connection rules/policies (e.g. features/description includes connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion), where a 
call is associated with a user/subscriber since the user/subscriber is the one making the 
call/connect), where each policy defines one more policy features of a group of policy features 
with which the related subscriber is associated (see col. 14, line 35-64; each rule/policy 
defines/describes the descriptions/features of connectively information, threshold, quality of 
service, capacity, and/or status of loading/congestion (i.e. a policy/rule for a quality of service 
feature/description of a group of features/descriptions connectively information, threshold, 
quality of service, capacity, and/or status of loading/congestion; a policy/rule for 
loading/congestion feature/description of a group of features/descriptions connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion) 
associated with a call/connection for the user/subscriber) where the policy server is to; 

wherein the policy server operates to effectuate a particular policy feature of the plurality 
of policy feature with respect to said call when triggered by the signaling message received from 
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said signaling intercept processor (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 
13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; RSD 
determines/decides whether a particular/specific quality-of-service rule/policy of the 
load/congestion/priority/bandwidth/route/quality-of-service condition of a new call/connection is 
met/fulfilled when receiving setup message from a user (via RRSD)). 

determining that a policy in the policy profile database is to be enforced for the calling 
party (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 18, line 45; 
see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 
13, line 1-6, 29-67; Tables VII-IX; according to a new call in the RSD database tables, 
deciding/determining a specific rule/policy to trigger/apply to received call's priority of traffic); 

execute for each policy feature of the one or more policy features identified by the policy 
for the calling party (FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 
18, line 45; see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1- 
16; see col. 13, line 1-6, 29-67; according to a new call, processing/executing in RSD for each 
status/feature (i.e. connectively information, threshold, quality of service, capacity, or status of 
loading/congestion) of a group of status/feature/priority (i.e. connectively information, threshold, 
quality of service, capacity, and status of loading/congestion) identify/recognized by the 
rule/policy associated with a call/connection for the user/subscriber); 

determine whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied with respect to the 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
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rule/policy condition/state (e.g. yellow, Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions)); 

where one ore more policy features, identified by the policy for the calling party, 
comprises an aggregated bandwidth limit feature (see col. 17, line 30-40; see col. 13, line 45-47; 
total bandwidth) and 

wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow, Red, and green), associated/related with connectively information, 
threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 

calculating bandwidth for the signaling message (see FIG. 8, step 840; see FIG. 10, steps 
1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 
19-30; Table VII, VIII; determining/calculating threshold capacity/bandwidth/Gbps of the 
requested new call/connection), 

determining whether calculated bandwidth exceeds a requested bandwidth (see FIG. 8, 
step 840; see FIG. 10, steps 1035, 1040; see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 
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25- to see col. 21, line 30; Table VII, VIII; determining/calculating the determined/calculated 
threshold capacity/bandwidth/Gbps with threshold capacity/bandwidth/Gbps is higher/exceed the 
requested/required capacity/bandwidth/Gbps), and 

determining that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 14, line 
10-7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table VII, VIII; ; determining 
that the condition/status (i.e. red/yellow) for the total bandwidth feature when the 
determined/calculated threshold capacity/bandwidth/Gbps is not higher/exceed the 
required/requested capacity/bandwidth/Gbps); 

a connection path being established when the policy condition for each policy feature, of 
the one or more policy features identified by the policy for the calling party, is determined to be 
satisfied (see FIG. 8, step 850, 860, 870; see FIG. 10, steps 1045, 1050, 1055; see col. 14, line 1- 
65; see col. 19, line 35-50; see col. 21, line 40-50; setting/establishing the call/connection when 
load/congestion/priority/bandwidth/routes conditions/status (i.e. connectively information, 
threshold, quality of service, capacity, or status of loading/congestion) are met/fulfilled for each 
policy/rule status/feature identified/recognized by the user/subscriber policy). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "the policy server being associated with a policy profile 
database " and "where one ore more policy features, identified by the policy for the calling 
party, comprises an aggregated bandwidth limit feature, wherein the determining whether a 
policy condition associated with each policy feature is satisfied, comprises: calculating 
bandwidth for the signaling message, determining whether calculated bandwidth exceeds a 
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requested bandwidth, determining that the condition is satisfied for the aggregate bandwidth 
limit feature when the calculated bandwidth is determined to not exceed the requested 
bandwidth ", as taught by Buyukkoc in the system of Hall'5 12, so that it would provide efficient 
means by which capacity in the network is more fully shared without adversely affecting call set 
up operations; see Buyukkoc col. 2, line 9-25. 

Moreover, the doctrine of double patenting seeks to prevent the unjustified extension of 
patent exclusivity beyond the term of a patent. 

Claim Rejections - 35 USC §101 

6. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 

7. Claims 39, 42-50, 54-56, 58-65 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non- statutory subject matter since it fails to be limited to embodiments 
which fall within a statutory category. 

Claim 39 recites, "a tangible computer readable medium operable with an Asynchrous 
Transfer Mode (ATM) network node, said computer-readable medium carrying a sequence of 
instructions provided for executing logic which, when executed by a processing entity. . ." in line 
1-3. 

It is noted that applicant fails to provide antecedent basis for the claim terminology 
"tangible computer readable medium" intended to be covered within the meaning in the 
disclosure. By simply adding "tangible" to the computer readable medium does not make the 
claim automatically statutory. Since the applicant fails to provide antecedent basic to limit the 
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specific statutory embodiments, "tangible computer readable medium" belongs to the intrinsic 
non-statutory embodiments of transitory medium such as a carrier signal, radio wave, light wave, 
and transmission medium/media. 

Transitory transmission media in the context of this disclosure cover "carrier signal, 
radio wave, light wave, transmission medium/media", which are not a Manufacture within the 
meaning of 101, and electrical connections, optical coaxial cables, copper wire and fiber optics 
fibers, on which the program is still unavailable to the processor. In such embodiments, the 
program is still unable to act as a computer component and have its functionality realized. Thus, 
claims that recite nothing but the physical characteristics of a form of energy, such as a 
frequency, voltage, or the strength of a magnetic field, define energy or magnetism, per se, and 
as such are nonstatutory natural phenomena. O'Reilly, 56 U.S. (15 How.) at 1 12-14. Thus, the 
claim is also non-statutory. 

In view of the above analysis, "tangible computer readable medium" is 
"physical/real/tangible" transmission medium/media where the signal is traversed. Thus, claim 
39 is ineligible for patent protection as failing to be limited to embodiments which fall within a 
statutory category. 

The United States Patent and Trademark Office (USPTO) is obliged to give claims their 
broadest reasonable interpretation consistent with the specification during proceedings before the 
USPTO. See In re Zletz, 893 F.2d 319 (Fed. Cir. 1989) (during patent examination the pending 
claims must be interpreted as broadly as their terms reasonably allow). The broadest reasonable 
interpretation of a claim drawn to a computer readable medium (also called machine readable 
medium and other such variations) typically covers forms of non-transitory tangible media and 
transitory propagating signals per se in view of the ordinary and customary meaning of computer 
readable media, particularly when the specification is silent. See MPEP 21 1 1 .01 . When the 
broadest reasonable interpretation of a claim covers a signal per se, the claim must be rejected 
under 35 US.C. § 101 as covering non-statutory subject matter. See In re Nuijten, 500 F.3d 1346, 
1356-57 (Fed. Cir. 2007) (transitory embodiments are not directed to statutory subject matter) 
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and Interim Examination Instructions for Evaluating Subject Matter Eligibility Under 35 Us. C. § 
101, Aug. 24, 2009; p. 2. 

Claims 42-50, 54-56, and 58-65 are also rejected since they are depended upon rejection 
claim 39 set forth above. 

Claim Rejections - 35 USC §103 

8. The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

9. Claim 1, 2, 3, 5, and 12 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc (US 6.463.062) in view of Gai (US006 167445 A). 

Regarding claim 1, Buyukkoc discloses a method in an synchronous Transfer Mode 
(ATM) network (see FIG. 7-9, a method performed by central Routing Status Database server, 
PvDS in ATM network; see col. 19, line 55-60) having an ingress switch (see FIG. 9, ATM 
switch 922) and an egress switch (see FIG. 9, ATM switch 924), wherein the ingress switch 
serves an ingress device (see FIG. 9, switch 912) operated by a calling party (see FIG. 9, User 
902) and the egress switch serves an egress device (see FIG. 9, Switch 914) operated by a called 
party (see FIG. 9, user 904); see col. 19, line 61 to col. 20, line 24), the method comprising: 

receiving, in the ingress switch, a signaling message from the ingress device (see FIG. 9, 
step 810, edge node receive anew call; see col. 19, line 19-26; also see FIG. 10, step 1005, 1010, 
1015, 1020, 1025, 1030; see col. 20, line 50-67); 
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providing the signaling message to a signaling intercept processor (see FIG. 7, a link 750 
to Regional RSD server, RRSD, 740; see col. 13, line 22-46) associated with the ingress switch 
(see col. 47 to col. 14, line 5; see FIG. 8, step 820; see col. 19, line 25-30; edge node send a call 
query/message to RSD; also see FIG. 10, step 1035); 

propagating the signaling message from the signaling intercept processor to a policy 
server (see FIG. 7, from regional RSD 740 (RRSD) via a link 770 to central RDS server 730, i.e., 
Signaling Control Point, SCP), the policy server being associated with a policy profile database 
(Tables VII-IX, RSD associated with a database), the policy profile database storing entries that 
relate subscriber to policies (see col. 14, line 9 to col. 15, line 50; see col. 10, line 10-20; see col. 
11, line 1-16; see col. 13, line 1-6, 29-67; RSD stores contents consists call/connection 
rules/policies (e.g. features/description includes connectively information, threshold, quality of 
service, capacity, and/or status of loading/congestion), where a call is associated with a 
user/subscriber since the user/subscriber is the one making the call/connect), where each policy 
defines one more policy features of a group of policy features with which the related subscriber 
is associated (see col. 14, line 35-64; each rule/policy defines/describes the descriptions/features 
of connectively information, threshold, quality of service, capacity, and/or status of 
loading/congestion (i.e. a policy/rule for a quality of service feature/description of a group of 
features/descriptions connectively information, threshold, quality of service, capacity, and/or 
status of loading/congestion; a policy/rule for loading/congestion feature/description of a group 
of features/descriptions connectively information, threshold, quality of service, capacity, and/or 
status of loading/congestion) associated with a call/connection for the user/subscriber); 
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Identifying in the policy profile database and based on the signaling message, a policy for 
the calling party (see col. 17, line 25 to col. 18, line 45; see col. 14, line 9 to col. 15, line 50; see 
col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; according to a new call, 
recognizing/identifying a specific rule/policy in the RSD rule/policy database tables VII-IX); 

determining, in the policy server and based on the signaling message, that the policy for 
the calling party is to be enforced (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 
17, line 25 to col. 18, line 45; see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; 
see col. 11, line 1-16; see col. 13, line 1-6, 29-67; Tables VII-IX; according to a new call in the 
RSD database tables, deciding/determining a specific rule/policy to trigger/apply to received 
call's priority of traffic); 

executing, in the policy server and based on the signaling message for each policy feature 
of the one or more policy features identified by the policy for the calling party (FIG. 8, step 840; 
see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 18, line 45; see col. 13, line 1-7, 64 to 
col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; 
according to a new call, processing/executing in RSD for each status/feature (i.e. connectively 
information, threshold, quality of service, capacity, or status of loading/congestion) of a group of 
status/feature/priority (i.e. connectively information, threshold, quality of service, capacity, and 
status of loading/congestion) identify/recognized by the rule/policy associated with a 
call/connection for the user/subscriber); 

determining whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied with respect to the 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
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to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions)); 

where one ore more policy features, identified by the policy for the calling party, 
comprises an aggregated bandwidth limit feature (see col. 17, line 30-40; see col. 13, line 45-47; 
total bandwidth) and 

wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow, Red, and green), associated/related with connectively information, 
threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 

calculating bandwidth for the signaling message (see FIG. 8, step 840; see FIG. 10, steps 
1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 
19-30; Table VII, VIII; determining/calculating threshold capacity/bandwidth/Gbps of the 
requested new call/connection), 



Application/Control Number: 09/766,943 
Art Unit: 2463 



Page 24 



determining whether calculated bandwidth exceeds a requested bandwidth (see FIG. 8, 
step 840; see FIG. 10, steps 1035, 1040; see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 
25- to see col. 21, line 30; Table VII, VIII; determining/calculating the determined/calculated 
threshold capacity/bandwidth/Gbps with threshold capacity/bandwidth/Gbps is higher/exceed the 
requested/required capacity/bandwidth/Gbps), and 

determining that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 14, line 
10-7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table VII, VIII; ; determining 
that the condition/status (i.e. red/yellow) for the total bandwidth feature when the 
determined/calculated threshold capacity/bandwidth/Gbps is not higher/exceed the 
required/requested capacity/bandwidth/Gbps); 

establishing a connection path between the ingress switch and the egress switch based on 
the determination that the policy condition is satisfied for each policy feature, of the one or more 
policy features identified by the policy for the calling party (see FIG. 8, step 850, 860, 870; see 
FIG. 10, steps 1045, 1050, 1055; see col. 14, line 1-65; see col. 19, line 35-50; see col. 21, line 
40-50; setting/establishing the call/connection when load/congestion/priority/bandwidth/routes 
conditions/status (i.e. connectively information, threshold, quality of service, capacity, or status 
of loading/congestion) are met/fulfilled for each policy/rule status/feature identified/recognized 
by the user/subscriber policy). 

Although Buyukkoc discloses executing in the policy server for each policy feature of the 
one or more policy features identified by the policy for the calling party as set forth above, 

Buyukkoc does not explicitly disclose "appropriate service logic". 
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However, Gai teaches the policy server (see FIG. 4, policy server 322) being associated 
with a policy profile database (see FIG. 4, a combined system of database policy rule 414, policy 
translator, repository 326 and device-specific filtering entity 416), the policy profile database 
storing entries that relate subscriber to policies (see FIG. 4, stores data related to user policies; 
see col. 13, line 61 to col. 14, line 5), where each policy defines one more policy features of a 
group of policy features with which the related subscriber is associated (see FIG. 4, each policy 
defines rules/policy features for a group of policy features (e.g. source address screening, 
Destination address screening features) for each user; see col. 14, line 1-15, 56 to col. 15, line 
55); 

identifying, in the policy profile database, a policy for the calling party (see FIG. 4, 
identifying/recognizing the policy for a calling user in the combined database system; see col. 
13, line 60 and col. 18, line 65); 

Determining, in the policy server and that the policy for the calling party is to enforced 
(see FIG. 4, determining the policy for the caller/user is to be managed/restricted/enforced in the 
policy server 322; see col. 13, line 60 and col. 18, line 65);; 

executing in the policy server appropriate service logic for each policy feature of the one 
ore more policy feature identified by the policy of the calling party (see FIG. 4, 
executing/processing specific engine/logic for each policy feature identified by the policy of 
caller/user; see col. 13, line 60 and col. 18, line 65); 

determining, whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied (see FIG. 4, 
determining if a policy condition/status related/associated with each policy/rule feature 
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identified/recognized by the policy/rule for the caller/user is accepted/satisfied; see col. 13, line 
60 and col. 18, line 65); 

an aggregated bandwidth limit feature (see col. 4, line 50 to col. 5, line 20; combined 
bandwidth processing) and 

wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 4, determining if a policy condition/status related/associated with each 
policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises : 

calculating bandwidth for the signaling message (see col. 4, line 50 to col. 5, line 20; see 
col. 14, line 1-25; see col. 18, line 45-65; computing/calculating bandwidth for the 
demand/request message/data) 

determining whether calculated bandwidth exceeds a requested bandwidth (see col. 4, 
line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking 
whether calculated/determined bandwidth exceed the SLA bandwidth), and 
determining that the condition is satisfied for the aggregate bandwidth limit feature when the 
calculated bandwidth is determined to not exceed the requested bandwidth (see col. 4, line 50 to 
col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking whether 
traffic condition is met/accepted for the combined bandwidth processing when the 
calculated/determined bandwidth is not exceed the request bandwidth (i.e. bandwith within 
SLA); 

establishing the connection path based on said determination that the policy condition is 
satisfied for each policy feature, of the one or more policy features identified by the policy for 
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the calling party (see FIG. 4, establishing a connection/communication base on determination 
that policy/rule status/condition is satisfied/meet for the policy/rule feature identified/recognized 
by the policy of the caller/user; see col. 13, line 60 and col. 18, line 65). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "appropriate service logic", as taught by Gai in the system of 
Buyukkoc, so that it would ability to allocate network services and resources by applying high- 
level quality of service policies; see Gai col. 5, line 45-55. 

Regarding claim 2, Buyukkoc discloses where the signaling message comprises a 
Connect message (see FIG. 8, step 850, a message which contains a route for new call is the 
connect message in ATM signaling/SS7; see col. 19, line 19-25, 40-45; see col. 20, line 39-45). 

Regarding claims 3 and 5, Buyukkoc discloses where the signaling message comprises 
an Add Party or setup message (see FIG. 8, steps 820,830; a message which contains a new call 
requesting for a route is the SETUP/adding party message in ATM signaling/SS7; see col. 19, 
line 19-31; see col. 20, line 46-52; see col. 20, line 39-45; see col. 21, line 19-25). 

Regarding claims 12, Buyukkoc discloses wherein where said particular one or more 
policy features, identified by the policy for the calling party comprises a service class selection 
feature (see col. 10, line 50-55; see col. 18, line 26-45; class-of-service) and where the 
determining whether a policy condition associated with each policy feature is satisfied (see FIG. 
8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, 
line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy condition/state (e.g. 
yellow, Red, and green), associated/related with connectively information, threshold, quality of 
service, capacity, or status of loading/congestion, identified/recognized by the rule/policy 
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associated with a call/connection for the user/subscriber is met/fulfilled according to a new 
call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions), comprises: 

determining a requested class of service based on the signaling message 
(determining/checking a requested/demand class of service based on a new call message; see col. 
14, line 1 to col. 18, line 66; see col. 19, line 10-55), 

determining whether the requested class of service is permitted for a customer logical 
port with which the calling party is associated (determine/checking if a requested/demand class 
of service based is not-block (i.e. permitted) for a ATM virtual link with VPI port number on a 
new call; see col. 14, line 1 to col. 18, line 66; see col. 19, line 10-55); and 

determining that the condition is satisfied for the service class selection feature when the 
requested class of service is permitted for the customer logical port with which the calling party 
is associated (determining/checking the condition/status (i.e. red/green/yellow) is met/satisfied 
for class of service when the requested/demand class of service is not-blocked (i.e. permitted) for 
a VPI port number on a new party; see col. 14, line 1 to col. 18, line 66; see col. 19, line 10-55). 

Gai also discloses a service class selection feature (see col. 3, line 5-60; class/type of 
service selection/choosing) and where the determining whether a policy condition associated 
with each policy feature is satisfied (see FIG. 4, determining if a policy condition/status 
related/associated with each policy/rule feature identified/recognized by the policy/rule for the 
caller/user is accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises: 
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determining a requested class of service based on the signaling message 
(determining/calculating a request type/class of service based on request/demand; col. 3, line 5- 
65; see col. 5, line 5-45; see col. 11, line 1 to col. 12, line 40), 

determining whether the requested class of service is permitted for a customer logical 
port with which the calling party is associated (determining/calculating if the requested/demand 
class/type of service allowed/permitted for a customer/user logical port/connection (i.e. ATM) 
with which the caller/subscriber is associated/related; col. 3, line 5-65; see col. 5, line 5-45; see 
col. 11, line 1 to col. 12, line 40); and 

determining that the condition is satisfied for the service class selection feature when the 
requested class of service is permitted for the customer logical port with which the calling party 
is associated (determining/checking if the condition/status for traffic is permitted/allow for the 
logic port with which the called/user is related; see col. 3, line 5-65; see col. 5, line 5-45; see col. 
11, line 1 to col. 12, line 40). 

10. Claim 4 is rejected under 35 U.S. C. 103(a) as being unpatentable over Buyukkoc in view 
of Gai and further in view of Noake (US006751222B1). 

Regarding claim 4, neither Buyukkoc nor Gai explicitly disclose a release message see 
FIG. 4, determining if a policy condition/status related/associated with each policy/rule feature 
identified/recognized by the policy/rule for the caller/user is accepted/satisfied; see col. 13, line 
60 and col. 18, line 65). 

However, a release message is well know in the ATM signaling/SS7 in order to 
disconnect the call. 
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In particular, Noake teaches a release message (see FIG. 4, RELEASE message; see col. 
8, line 9-39). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide a release message, as taught by Noake in the combined 
system of Buyukkoc and Gai, so that it would make effective use of a band and the respective 
apparatus by transmitting connection information, and by sending/receiving a release message it 
will notify to stop the cell assembling and disassembling processes; see Noake col. 2, line 55-64; 
col. 8, line 19-24. 

1 1 . Claim 7 is rejected under 35 U.S. C. 103(a) as being unpatentable over Buyukkoc in view 
of Gai and further in view of Farris (US006 154445 A). 

Regarding claim 7, Buyukkoc discloses wherein where said particular one or more 
policy features, identified by the policy for the calling party comprises a call feature (see col. 10, 
line 50-55; see col. 18, line 26-45; call/connection type feature) and where the determining 
whether a policy condition associated with each policy feature is satisfied (see FIG. 8, step 840; 
see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; 
see col. 21, line 19-30; determines/decides whether rule/policy condition/state (e.g. yellow, Red, 
and green), associated/related with connectively information, threshold, quality of service, 
capacity, or status of loading/congestion, identified/recognized by the rule/policy associated with 
a call/connection for the user/subscriber is met/fulfilled according to a new call/connection (i.e. 
load/congestion/priority /bandwidth/routes/quality-of-service states/conditions), comprises: 
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determining whether the signaling message result for a customer logical port with which 
the calling party is associated (determine/checking if a requested/demand class of service based 
is not-block (i.e. permitted) for a ATM virtual link with VPI port number on a new call; see col. 
14, line 1 to col. 18, line 66; see col. 19, line 10-55); and 

determining that the condition is satisfied for the call feature when the requested the 
signaling message does not result for the customer logical port with which the calling party is 
associated (determining/checking the condition/status (i.e. red/green/yellow) is met/satisfied for 
type of call when the requested/demand call type is not-blocked (i.e. permitted) for a VPI port 
number on a new party; see col. 14, line 1 to col. 18, line 66; see col. 19, line 10-55). 

Gai also discloses call feature (see col. 3, line 5-60; class/type of service 
selection/choosing) and where the determining whether a policy condition associated with each 
policy feature is satisfied (see FIG. 4, determining if a policy condition/status related/associated 
with each policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises: 

determining call type feature based on the signaling message (determining/calculating a 
request call type based on request/demand; col. 3, line 5-65; see col. 5, line 5-45; see col. 11, line 
1 to col. 12, line 40), 

determining whether the requested call type feature is permitted for a customer logical 
port with which the calling party is associated (determining/calculating if the requested/demand 
call type allowed/permitted for a customer/user logical port/connection (i.e. ATM) with which 
the caller/subscriber is associated/related; col. 3, line 5-65; see col. 5, line 5-45; see col. 11, line 
1 to col. 12, line 40); and 
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determining that the condition is satisfied for the call type feature when the requested call 
type feature does not result for the customer logical port with which the calling party is 
associated (determining/checking if the condition/status for traffic is permitted/allow for the 
logic port with which the called/user is related; see col. 3, line 5-65; see col. 5, line 5-45; see col. 

11, line 1 to col. 12, line 40). 

Neither Buyukkoc nor Gai explicitly disclose "a maximum call attempt rate limit." 

However, having a maximum call attempt rate limit/threshold is well known in the 
signaling/SS7. In particular, Farris teaches a maximum call attempt rate limit (see col. 14, line 1- 
12; see col. 11, line 5-17; acceptable/maximum specified rate of call attempts). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "acceptable/maximum specified rate of call attempts", as 
taught by Farris in the combined system of Buyukkoc and Gai, so that it would can detect the 
predetermined events and/or imminence of predetermined events, and then blocking or 
controlling those events from their incipiency; see Farris col. 14, line 1-6. 

12. Claims 6, 8, 9 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Gai, and further in view of Christie'656 (US006690656B1). 

Regarding claims 6, 8, and 9, Buyukkoc discloses where said particular one or more 
policy features, identified by the policy for the calling party, comprises a address validation 
feature and where the determining whether a policy condition associated with each policy feature 
is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 
14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
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rule/policy condition/state (e.g. yellow, Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions) comprises 

determining whether an address associated with the calling party (see col. 3, line 5-65; 
see col. 7, line 50 to col. 16, line 65; determining/checking the call/connection of 
user/subscriber), and 

determining that the condition is satisfied for the address validation feature (see col. 3, 
line 5-65; see col. 7, line 50 to col. 16, line 65; determining that status/condition (i.e. green, 
yellow, red) is met/satisfied for the address checking/verification). 

Gai discloses disclose a address validation/screening and address screening herein 
where said particular one or more policy features, identified by the policy for the calling party, 
comprises address validation feature and where the determining whether a policy condition 
associated with each policy feature is satisfied comprises: determining whether an address 
associated with the calling party, and determining that the condition is satisfied for the address 
validation feature when the address, associated with the calling party (see FIG. 4- 6, and 7A; see 
col. 9, line 58 to col. 20, line 30). 

Neither Buyukkoc nor Gai explicitly disclose "within a range of authorized addresses ", 
"when the address, associated with the calling party, is determined to be within the range of 
authorized addresses". 

However, a source address validation/screening is well known in the ATM signaling/SS7. 



Application/Control Number: 09/766,943 Page 34 

Art Unit: 2463 

In particular, Christie'656 teaches a source address validation/screening and a destination 
address screening herein where said particular one or more policy features, identified by the 
policy for the calling party, comprises a source address validation feature (see FIG. 7, step 720, 
720, 730; policy/rule validation/verification identify the caller is the caller (source) and called 
(destination) addresses/number/IDs validation; see col. 7, line 5-55; see col. 15, line 30-60) and 

determining whether an address associated with the calling party is within a range of 
authorized addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining whether the caller 
address with within a range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range), and 

determining that the condition is satisfied for the source address validation feature when 
the address, associated with the calling party, is determined to be within the range of authorized 
addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining the status/condition is 
met/accepted/satisfied for the caller ID/number/addresses/ANI associated with the caller is 
determined to be within range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to "within a range of authorized addresses ", "when the address, 
associated with the calling party, is determined to be within the range of authorized addresses" ., 
as taught by Christie'656 in the combined system of Buyukkoc and Gai, so that it would can 
validate the calls and generate a billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39- 
45. 
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13. Claims 14-16, 18, 31, 39, 42, 43, 45 and 58 14 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Buyukkoc in view of Gai and Smith (US006222823B1). 

Regarding claim 14, Buyukkoc discloses an Asynchronous Transfer Mode (ATM) 
network (see FIG. 7-9, ATM network; see col. 19, line 55-60) for effectuating intelligent policy 
features with respect to a call to be established between a calling party and a called party (see 
FIG. 9, a connection user 904 and 902; see col. 19, line 61 to col. 20, line 24), comprising: 

an ATM switch (see FIG. 9, ATM switch 922) serving a customer premises equipment 
(CPE) operated by the calling party (see FIG. 9, CPE User 902 connects TDM switch 912; see 
col. 19, line 64 to col. 20, line 25); 

a signaling intercept processor (see FIG. 7, Regional RSD server, RRSD, 740; see col. 
13, line 22-46) associated with said ATM switch, the signaling intercept processor to intercept a 
signaling message relative to said call (see col. 47 to col. 14, line 5; see FIG. 8, step 820; see col. 
19, line 25-30; edge node send a call query/message to RSD, thus RSD intercept/capture the call 
query/message; also see FIG. 10, step 1035); 

a policy server (see FIG. 7, central RDS server 730, i.e., Signaling Control Point, SCP) 
associated with said signaling intercept processor, the policy server being associated with a 
policy profile database (Tables VII-IX, RSD associated with a database), the policy profile 
database storing entries that relate subscriber to policies (see col. 14, line 9 to col. 15, line 50; see 
col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD stores contents 
consists call/connection rules/policies (e.g. features/description includes connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion), where a 
call is associated with a user/subscriber since the user/subscriber is the one making the 
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call/connect), where each policy defines one more policy features of a group of policy features 
with which the related subscriber is associated (see col. 14, line 35-64; each rule/policy 
defines/describes the descriptions/features of connectively information, threshold, quality of 
service, capacity, and/or status of loading/congestion (i.e. a policy/rule for a quality of service 
feature/description of a group of features/descriptions connectively information, threshold, 
quality of service, capacity, and/or status of loading/congestion; a policy/rule for 
loading/congestion feature/description of a group of features/descriptions connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion) 
associated with a call/connection for the user/subscriber) where the policy server is to; 

wherein the policy server operates to effectuate a particular policy feature of the plurality 
of policy feature with respect to said call when triggered by the signaling message received from 
said signaling intercept processor (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 
13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; RSD 
determines/decides whether a particular/specific quality-of-service rule/policy of the 
load/congestion/priority/bandwidth/route/quality-of-service condition of a new call/connection is 
met/fulfilled when receiving setup message from a user (via RRSD)). 

determining that a policy in the policy profile database is to be enforced for the calling 
party (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 18, line 45; 
see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 
13, line 1-6, 29-67; Tables VII-IX; according to a new call in the RSD database tables, 
deciding/determining a specific rule/policy to trigger/apply to received call's priority of traffic); 
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execute for each policy feature of the one or more policy features identified by the policy 
for the calling party (FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 
18, line 45; see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1- 
16; see col. 13, line 1-6, 29-67; according to a new call, processing/executing in RSD for each 
status/feature (i.e. connectively information, threshold, quality of service, capacity, or status of 
loading/congestion) of a group of status/feature/priority (i.e. connectively information, threshold, 
quality of service, capacity, and status of loading/congestion) identify/recognized by the 
rule/policy associated with a call/connection for the user/subscriber); 

determine whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied with respect to the 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions)); 

a connection path being established when the policy condition for each policy feature, of 
the one or more policy features identified by the policy for the calling party, is satisfied (see FIG. 
8, step 850, 860, 870; see FIG. 10, steps 1045, 1050, 1055; see col. 14, line 1-65; see col. 19, line 
35-50; see col. 21, line 40-50; setting/establishing the call/connection when 
load/congestion/priority/bandwidth/routes conditions/status (i.e. connectively information, 
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threshold, quality of service, capacity, or status of loading/congestion) are met/fulfilled for each 
policy/rule status/feature identified/recognized by the user/subscriber policy); 

one ore more policy features, identified by the policy for the calling party, comprises an 
aggregated bandwidth limit feature for a particular network port by said calling party (see col. 
17, line 30-40; see col. 13, line 45-47; total bandwidth; (see FIG. 9, physical trunk/port 932; see 
col. 20, line 1-10; col. 17, line 30-40; see col. 13, line 45-47; total bandwidth for the port/link) 

Where, when determining whether a policy condition associated with each policy feature 
is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 
14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions) the policy server is to: 

calculate bandwidth for the signaling message (see FIG. 8, step 840; see FIG. 10, steps 
1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 
19-30; Table VII, VIII; determining/calculating threshold capacity/bandwidth/Gbps of the 
requested new call/connection), 

determine whether calculated bandwidth exceeds a requested bandwidth (see FIG. 8, step 
840; see FIG. 10, steps 1035, 1040; see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- 
to see col. 21, line 30; Table VII, VIII; determining/calculating the determined/calculated 
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threshold capacity/bandwidth/Gbps with threshold capacity/bandwidth/Gbps is higher/exceed the 
requested/required capacity/bandwidth/Gbps), and 

determine that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 14, line 
10-7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table VII, VIII; ; determining 
that the condition/status (i.e. red/yellow) for the total bandwidth feature when the 
determined/calculated threshold capacity/bandwidth/Gbps is not higher/exceed the 
required/requested capacity/bandwidth/Gbps). 

Although Buyukkoc discloses executing in the policy server for each policy feature of the 
one or more policy features identified by the policy for the calling party as set forth above, 

Buyukkoc does not explicitly disclose "appropriate service logic". 

However, Gai teaches the policy server (see FIG. 4, policy server 322) being associated 
with said intercept processor, the policy server being associated with a policy profile database 
(see FIG. 4, a combined system of database policy rule 414, policy translator, repository 326 and 
device-specific filtering entity 416), the policy profile database storing entries that relate 
subscriber to policies (see FIG. 4, stores data related to user policies; see col. 13, line 61 to col. 
14, line 5), where each policy defines one more policy features of a group of policy features with 
which the related subscriber is associated (see FIG. 4, each policy defines rules/policy features 
for a group of policy features (e.g. source address screening, Destination address screening 
features) for each user; see col. 14, line 1-15, 56 to col. 15, line 55) where the policy server is to: 



Application/Control Number: 09/766,943 Page 40 

Art Unit: 2463 

determine that a policy in the policy profile database is to be enforced for the calling 
party (see FIG. 4, determining a policy for the caller/user in the combined database system is to 
be managed/restricted/enforced for caller user; see col. 13, line 60 and col. 18, line 65); 

execute in the policy server appropriate service logic for each policy feature of the one 
ore more policy feature identified by the policy of the calling party (see FIG. 4, 
executing/processing specific engine/logic for each policy feature identified by the policy of 
caller/user; see col. 13, line 60 and col. 18, line 65); 

determining, whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied (see FIG. 4, 
determining if a policy condition/status related/associated with each policy/rule feature 
identified/recognized by the policy/rule for the caller/user is accepted/satisfied; see col. 13, line 
60 and col. 18, line 65); 

a connection path being established when the policy condition for each policy feature, of 
the one or more policy features identified by the policy for the calling party is determined to be 
satisfied (see FIG. 4, establishing a connection/communication base on determination that 
policy/rule status/condition is satisfied/meet for the policy/rule feature identified/recognized by 
the policy of the caller/user; see col. 13, line 60 and col. 18, line 65); 

an aggregated bandwidth limit feature (see col. 4, line 50 to col. 5, line 20; combined 
bandwidth processing) and 

wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 4, determining if a policy condition/status related/associated with each 
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policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises : 

calculating bandwidth for the signaling message (see col. 4, line 50 to col. 5, line 20; see 
col. 14, line 1-25; see col. 18, line 45-65; computing/calculating bandwidth for the 
demand/request message/data) 

determining whether calculated bandwidth exceeds a requested bandwidth (see col. 4, 
line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking 
whether calculated/determined bandwidth exceed the SLA bandwidth), and 

determining that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 4, line 50 
to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking whether 
traffic condition is met/accepted for the combined bandwidth processing when the 
calculated/determined bandwidth is not exceed the request bandwidth (i.e. bandwith within 
SLA). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "appropriate service logic", as taught by Gai in the system of 
Buyukkoc, so that it would ability to allocate network services and resources by applying high- 
level quality of service policies; see Gai col. 5, line 45-55. 

Neither Buyukkoc nor Gai explicitly disclose "authorized for use ". 

However, determining the maximum bandwidth allowable for a particular port authorized 
for use by said party is well known in the art of ATM. In particular, Smith teaches determining 
the maximum bandwidth allowable for a particular port authorized for use by said party (see 
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FIG. 1-2; see col. 9, line 5-45, and abstract; determining predetermined/allowable/authorized 
bandwidth for a particular port/connection of end station). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to determining predetermined/allowable/authorized bandwidth for a 
particular port/connection of end station, as taught by Smith in the combined system of 
Buyukkoc and Gai, so that it would cause the system control means to allocate a predetermined 
bandwidth and balance the bandwidth; see Smith col. 2, line 35-67; col. 9, line 21-25. 

Regarding claim 39, Buyukkoc discloses a computer-readable medium operable with an 
Asynchronous Transfer Mode (ATM) network node (see FIG. 9, ATM switch 922,924 with 
memory 1 104; see col. 22, line 12-40), said computer-readable medium carrying a sequence of 
instructions provided for executing service logic which, when executed by a processing entity 
associated with said ATM network node, (see FIG. 11, see col. 22, line 12-40) causes said ATM 
network node to perform the steps of: 

receiving in said ATM network node a signaling message with respect to a call from a 
calling party (see FIG. 9, User 902; see FIG. 9, step 810, edge node receive a new call; see col. 
19, line 19-26; also see FIG. 10, step 1005,1010,1015,1020,1025,1030; see col. 20, line 50-67); 
and 

identifying in the policy profile database associated with the ATM network node and 
based and based on the signaling message, a policy for the calling party (see col. 17, line 25 to 
col. 18, line 45; see col. 14, line 9 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1- 
16; see col. 13, line 1-6, 29-67; according to a new call, recognizing/identifying a specific 
rule/policy in the RSD rule/policy database tables VII-IX); 
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the policy profile database (Tables VII-IX, RSD associated with a database), the policy 
profile database storing entries that relate subscriber to policies (see col. 14, line 9 to col. 15, line 
50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD stores 
contents consists call/connection rules/policies (e.g. features/description includes connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion), where a 
call is associated with a user/subscriber since the user/subscriber is the one making the 
call/connect), where each policy defines one more policy features of a group of policy features 
with which the related subscriber is associated (see col. 14, line 35-64; each rule/policy 
defines/describes the descriptions/features of connectively information, threshold, quality of 
service, capacity, and/or status of loading/congestion (i.e. a policy/rule for a quality of service 
feature/description of a group of features/descriptions connectively information, threshold, 
quality of service, capacity, and/or status of loading/congestion; a policy/rule for 
loading/congestion feature/description of a group of features/descriptions connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion) 
associated with a call/connection for the user/subscriber) 

executing, based on the signaling message, for each policy feature of the one or more 
policy features identified by the policy for the calling party (FIG. 8, step 840; see FIG. 10, steps 
1035,1040; see col. 17, line 25 to col. 18, line 45; see col. 13, line 1-7, 64 to col. 15, line 50; see 
col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; according to a new call, 
processing/executing in RSD for each status/feature (i.e. connectively information, threshold, 
quality of service, capacity, or status of loading/congestion) of a group of status/feature/priority 
(i.e. connectively information, threshold, quality of service, capacity, and status of 
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loading/congestion) identify/recognized by the rule/policy associated with a call/connection for 
the user/subscriber); 

determining whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied with respect to the 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions)); 

one ore more policy features, identified by the policy for the calling party, comprises an 
aggregated bandwidth limit feature for a particular network port by said calling party (see col. 
17, line 30-40; see col. 13, line 45-47; total bandwidth; (see FIG. 9, physical trunk/port 932; see 
col. 20, line 1-10; col. 17, line 30-40; see col. 13, line 45-47; total bandwidth for the port/link) 

Where, when determining whether a policy condition associated with each policy feature 
is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 
14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
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is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions) the policy server is to: 

calculate bandwidth for the signaling message (see FIG. 8, step 840; see FIG. 10, steps 
1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 
19-30; Table VII, VIII; determining/calculating threshold capacity/bandwidth/Gbps of the 
requested new call/connection), 

determine whether calculated bandwidth exceeds a requested bandwidth (see FIG. 8, step 
840; see FIG. 10, steps 1035, 1040; see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- 
to see col. 21, line 30; Table VII, VIII; determining/calculating the determined/calculated 
threshold capacity/bandwidth/Gbps with threshold capacity/bandwidth/Gbps is higher/exceed the 
requested/required capacity/bandwidth/Gbps), and 

determine that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 14, line 
10-7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table VII, VIII; ; determining 
that the condition/status (i.e. red/yellow) for the total bandwidth feature when the 
determined/calculated threshold capacity/bandwidth/Gbps is not higher/exceed the 
required/requested capacity/bandwidth/Gbps); 

upon determining that the policy condition associated with each policy feature of one or 
more policy feature identified by the policy for the calling party is satisfied with respect to the 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with connectively 
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information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions)), causing a connection path to be 
established between the calling party and the call party (see FIG. 8, step 850, 860, 870; see FIG. 
10, steps 1045, 1050, 1055; see col. 14, line 1-65; see col. 19, line 35-50; see col. 21, line 40-50; 
setting/establishing the call/connection when load/congestion/priority/bandwidth/routes 
conditions/status (i.e. connectively information, threshold, quality of service, capacity, or status 
of loading/congestion) are met/fulfilled for each policy/rule status/feature identified/recognized 
by the user/subscriber policy). 

Although Buyukkoc discloses executing in the policy server for each policy feature of the 
one or more policy features identified by the policy for the calling party as set forth above, 

Buyukkoc does not explicitly disclose "appropriate service logic". 

However, Gai teaches the policy server (see FIG. 4, policy server 322) being associated 
with said intercept processor, the policy server being associated with a policy profile database 
(see FIG. 4, a combined system of database policy rule 414, policy translator, repository 326 and 
device-specific filtering entity 416), the policy profile database storing entries that relate 
subscriber to policies (see FIG. 4, stores data related to user policies; see col. 13, line 61 to col. 
14, line 5), where each policy defines one more policy features of a group of policy features with 
which the related subscriber is associated (see FIG. 4, each policy defines rules/policy features 
for a group of policy features (e.g. source address screening, Destination address screening 
features) for each user; see col. 14, line 1-15, 56 to col. 15, line 55) where the policy server is to: 
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determine that a policy in the policy profile database is to be enforced for the calling 
party (see FIG. 4, determining a policy for the caller/user in the combined database system is to 
be managed/restricted/enforced for caller user; see col. 13, line 60 and col. 18, line 65); 

execute in the policy server appropriate service logic for each policy feature of the one 
ore more policy feature identified by the policy of the calling party (see FIG. 4, 
executing/processing specific engine/logic for each policy feature identified by the policy of 
caller/user; see col. 13, line 60 and col. 18, line 65); 

determining, whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied (see FIG. 4, 
determining if a policy condition/status related/associated with each policy/rule feature 
identified/recognized by the policy/rule for the caller/user is accepted/satisfied; see col. 13, line 
60 and col. 18, line 65); 

an aggregated bandwidth limit feature (see col. 4, line 50 to col. 5, line 20; combined 
bandwidth processing) and 

wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 4, determining if a policy condition/status related/associated with each 
policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises : 

calculating bandwidth for the signaling message (see col. 4, line 50 to col. 5, line 20; see 
col. 14, line 1-25; see col. 18, line 45-65; computing/calculating bandwidth for the 
demand/request message/data) 
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determining whether calculated bandwidth exceeds a requested bandwidth (see col. 4, 
line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking 
whether calculated/determined bandwidth exceed the SLA bandwidth), and 

determining that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 4, line 50 
to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking whether 
traffic condition is met/accepted for the combined bandwidth processing when the 
calculated/determined bandwidth is not exceed the request bandwidth (i.e. bandwith within 
SLA); 

a connection path being established when the policy condition for each policy feature, of 
the one or more policy features identified by the policy for the calling party is determined to be 
satisfied (see FIG. 4, establishing a connection/communication base on determination that 
policy/rule status/condition is satisfied/meet for the policy/rule feature identified/recognized by 
the policy of the caller/user; see col. 13, line 60 and col. 18, line 65). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "appropriate service logic", as taught by Gai in the system of 
Buyukkoc, so that it would ability to allocate network services and resources by applying high- 
level quality of service policies; see Gai col. 5, line 45-55. 

Neither Buyukkoc nor Gai explicitly disclose "authorized for use ". 

However, determining the maximum bandwidth allowable for a particular port authorized 
for use by said party is well known in the art of ATM. In particular, Smith teaches determining 
the maximum bandwidth allowable for a particular port authorized for use by said party (see 
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FIG. 1-2; see col. 9, line 5-45, and abstract; determining predetermined/allowable/authorized 
bandwidth for a particular port/connection of end station). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to determining predetermined/allowable/authorized bandwidth for a 
particular port/connection of end station, as taught by Smith in the combined system of 
Buyukkoc and Gai, so that it would cause the system control means to allocate a predetermined 
bandwidth and balance the bandwidth; see Smith col. 2, line 35-67; col. 9, line 21-25. 

Regarding claim 15, Buyukkoc discloses where the signaling message comprises a 
Connect message (see FIG. 8, step 850, a message which contains a route for new call is the 
connect message in ATM signaling/SS7; see col. 19, line 19-25, 40-45; see col. 20, line 39-45). 

Regarding claims 16, 18, 43 and 45, Buyukkoc discloses where the signaling message 
comprises an Add Party or setup message (see FIG. 8, steps 820,830; a message which contains a 
new call requesting for a route is the SETUP/adding party message in ATM signaling/SS7; see 
col. 19, line 19-31; see col. 20, line 46-52; see col. 20, line 39-45; see col. 21, line 19-25). 

Regarding claim 31, the combined system of Buyukkoc and Gai discloses all limitation 
of claim 3 1 as set forth in claim above. Buyukkoc discloses a service class selection feature for 
specifying a service class with respect to a network port used by said party (see col. 10, line 50- 
55; see col. 18, line 26-45; see FIG. 9, trunk/port 932; see col. 20, line 1-10; selecting a class-of- 
service for a port/link/trunk/circuit used by the call). 

Regarding claim 42, Buyukkoc discloses wherein the signaling message comprises a 
Connect message (see FIG. 8, step 850, a message which contains a route for new call is the 
connect message in ATM signaling/SS7; see col. 19, line 19-25, 40-45; see col. 20, line 39-45). 
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Regarding claim 58, the combined system of Buyukkoc and Gai discloses all limitations 
as set forth in claims above. Buyukkoc further discloses a service class selection feature for 
specifying a service class with respect to a network port used by said party (see col. 10, line 50- 
55; see col. 18, line 26-45; see FIG. 9, trunk/port 932; see col. 20, line 1-10; selecting a class-of- 
service for a port/link/trunk/circuit used by the call). 

14. Claim 10 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai and VanDervort (US005761 191 A), or Horn (US005276676A). 

Regarding claim 10, Buyukkoc discloses wherein where said particular one or more 
policy features, identified by the policy for the calling party, comprises a maximum size limit 
(see col. 14, line 15-65; acceptable/maximum load/size/bandwidth before the call are blocked) 
and where the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow, Red, and green), associated/related with connectively information, 
threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 

determining whether a size in the signaling message exceeds a limit (see col. 14, line 10- 
7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; determining/checking if the 
acceptable size/load/capacity in the new call exceed threshold) , and 
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determining that the policy condition is satisfied for the maximum size limit feature when 
the size does not exceed the limit (see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- to 
see col. 21, line 30; determining the condition/status (e.g. red, yellow, green) is met/satisfied for 
the acceptable/maximum load/size/bandwidth when it does not exceed threshold). 

Gai also discloses wherein where said particular one or more policy features, identified 
by the policy for the calling party, comprises a maximum size limit and where the determining 
whether a policy condition associated with each policy feature is satisfied comprises: 
determining whether a burst size in the signaling message exceeds a limit, and determining that 
the condition is satisfied for the maximum burst size limit feature when the burst size does not 
exceed the limit (see FIG. 4- 6, and 7A; see col. 9, line 58 to col. 20, line 30). 

Neither Buyukkoc nor Gai explicitly disclose "burst". 

However, ATM network having a rule/policy/policing attribute burst size 
threshold/limiting for ATM flow control is well known in the art. 

In particular, VanDervort teaches a maximum burst size limit/threshold feature; 
determining whether a burst size in the signaling message exceeds a limit, and determining that 
the condition is satisfied for the maximum burst size limit feature when the burst size does not 
exceed the limit (see col. 6, line 8-11; limited/maximum burst size limit/threshold of user cell 
transmission for policing). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "burst", as taught by VanDervort in the combined system of 
Buyukkoc and Gai, so that it would control the flow of traffic and maximize the utilization of 
network resources; see VanDervort col. 6, line 1-3. 
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In particular, Horn teaches a maximum burst size limit/threshold feature and determining 
that the condition is satisfied for the maximum burst size limit feature when the burst size does 
not exceed the limit (see col. 2, line 29-30; maximum burst length is limited by threshold). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "burst", as taught by Horn in the combined system of 
Buyukkoc and Gai, so that it would avoid overflow problem due to long bursts; see Horn col. 1, 
line 25-34. 

15. Claim 13 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai and Basso (US006633539B1). 

Regarding claim 13, Buyukkoc discloses one ore more policy features, identified by the 
policy for the calling party, comprises an maximum call limit feature (see col. 17, line 30-40; see 
col. 13, line 45-47; see col. 14, line 15-65; acceptable/maximum call load/limit/bandwidth) and 

wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow, Red, and green), associated/related with connectively information, 
threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 
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determining whether maximum call limit, if a call is established between the calling party 
and called party, exceeds a requested bandwidth (see FIG. 8, step 840; see FIG. 10, steps 1035, 
1040; see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table 
VII, VIII; determining/calculating call load/limit/bandwidth is higher/exceed the 
requested/required maximum/acceptable load/limit/bandwidth), and 

determining that the condition is satisfied for the maximum call limit feature when the 
call does not exceed maximum call of calls (see col. 14, line 10-7 to col. 18, line 45; see col. 19, 
line 25- to see col. 21, line 30; Table VII, VIII; determining that the condition/status (i.e. 
red/yellow) for the acceptable/maximum call load/limit/bandwidth when the call is not 
higher/exceed the accepted/maximum calls). 

Gai also discloses maximum call limit feature (see col. 4, line 50 to col. 5, line 20; 
combined bandwidth processing) and wherein the determining whether a policy condition 
associated with each policy feature is satisfied (see FIG. 4, determining if a policy 
condition/status related/associated with each policy/rule feature identified/recognized by the 
policy/rule for the caller/user is accepted/satisfied; see col. 13, line 60 and col. 18, line 65) 
comprises: determining whether maximum call limit, if a call is established between the calling 
party and called party, exceeds a requested bandwidth determining that the condition is satisfied 
for the maximum call limit feature when the call does not exceed maximum call of calls (see col. 
4, line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65). 

Neither Buyukkoc nor Gai explicitly disclose "concurrent" . 

However, ATM network having a maximum concurrent call limit/threshed for call 
admission control (CAC) is well known in the art. In particular, Basso teaches a maximum 
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concurrent call limit feature (see col. 4, line 25-35; maximum allowed/limit number of 
concurrent connection/call). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "concurrent" , as taught by Basso in the combined system of 
Buyukkoc and Gai, so that it would control concurrent connections/calls to provide efficient 
protection against signaling congestion; see Basso col. 2, line 35-45. 

16. Claim 17 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai and Smith further in view of Noake (US006751222B1). 

Regarding claim 17, neither Buyukkoc, Gai nor Smith explicitly disclose a release 
message see FIG. 4, determining if a policy condition/status related/associated with each 
policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65). 

However, a release message is well know in the ATM signaling/SS7 in order to 
disconnect the call. 

In particular, Noake teaches a release message (see FIG. 4, RELEASE message; see col. 
8, line 9-39). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide a release message, as taught by Noake in the combined 
system of Buyukkoc, Smith and Gai, so that it would make effective use of a band and the 
respective apparatus by transmitting connection information, and by sending/receiving a release 
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message it will notify to stop the cell assembling and disassembling processes; see Noake col. 2, 
line 55-64; col. 8, line 19-24. 

17. Claims 19-21, 23-26, 46-48 and 50 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Buyukkoc in view of Gai and Smith, and further in view of Christie'656 
(US006690656B1). 

Regarding claim 19, the combination of Buyukkoc, Gai, Smith and Christie'656 
discloses all claimed limitations as set forth in claims above. Buyukkoc discloses accessing said 
ATM network through a particular network port associated with said CPE (see FIG. 9, accessing 
Switch 922 through the trunk/port 932; see col. 20, line 1-10). Christie'656 teaches a source 
address validation for ensuring that said party is an authorized party for accessing the ATM 
network (see FIG. 7; see col. 7, line 9-19, 35-45; checking/validating caller number in ANI for 
verification for accessing ATM network). 

Regarding claim 20, Buyukkoc discloses wherein said particular network port is a 
Customer Logical Port (see col. 4, line 20-40; see col. 5, line 20-26; edge node/switch provides 
logical connection/port (e.g. VPI port) between customer and the network). Christie'656 also 
discloses a Customer Logical Port (see col. 4, line 35-40; 60-67; a logical/virtual port/link). 

Regarding claim 21, Buyukkoc discloses wherein said particular network port is a full 
physical port (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10). 

Regarding claim 23 and 50, Buyukkoc discloses where said particular one or more 
policy features, identified by the policy for the calling party, comprises a address validation 
feature and where the determining whether a policy condition associated with each policy feature 
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is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 
14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions) comprises 

determining whether an address associated with the calling party (see col. 3, line 5-65; 
see col. 7, line 50 to col. 16, line 65; determining/checking the call/connection of 
user/subscriber), and 

determining that the condition is satisfied for the address validation feature (see col. 3, 
line 5-65; see col. 7, line 50 to col. 16, line 65; determining that status/condition (i.e. green, 
yellow, red) is met/satisfied for the address checking/verification). 

Gai discloses disclose a address validation/screening and address screening herein 
where said particular one or more policy features, identified by the policy for the calling party, 
comprises address validation feature and where the determining whether a policy condition 
associated with each policy feature is satisfied comprises: determining whether an address 
associated with the calling party, and determining that the condition is satisfied for the address 
validation feature when the address, associated with the calling party (see FIG. 4- 6, and 7A; see 
col. 9, line 58 to col. 20, line 30). 

Neither Buyukkoc, Smith nor Gai explicitly disclose "within a range of authorized 
addresses ", "when the address, associated with the calling party, is determined to be within the 
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range of authorized addresses", and "a destination address screening for defining a plurality of 
address to which said party can effectuate said call". 

However, a destination address validation/screening is well known in the ATM 
signaling/SS7, and a destination address/number validation/screening for defining a plurality of 
address/numbers to which said party can effectuate said call is well known in the signaling with 
SCP. 

In particular, Christie'656 teaches a destination address validation/screening and a 
destination address screening herein where said particular one or more policy features, identified 
by the policy for the called party, comprises a destination address validation feature (see FIG. 7, 
step 720, 720, 730; policy/rule validation/verification identify the called (destination) 
addresses/number/IDs validation; see col. 7, line 5-55; see col. 15, line 30-60) and 

determining whether destination address associated with the called party is within a range 
of authorized addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining whether the 
called address with within a range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range), and 

determining that the condition is satisfied for the destination address validation feature 
when the address, associated with the called party, is determined to be within the range of 
authorized addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining the 
status/condition is met/accepted/satisfied for the called ID/number/addresses/ANI is determined 
to be within range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range); 
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a destination address screening for defining a plurality of address to which said party can 
effectuate said call (see FIG. 7; see col. 7, line 9-19, 35-45; see col. 15, line 40-60; see col. 2, 
line 1-15; verifying a dial number from the list of numbers where the call needs to be connected). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to "within a range of authorized addresses ", "when the address, 
associated with the calling party, is determined to be within the range of authorized addresses", 
and "validate/verify dial number from the list of number to establish the call", as taught by 
Christie'656 in the combined system of Buyukkoc, Smith and Gai, so that it would can validate 
the calls and generate a billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claim 24, the combined of Buyukkoc, Gai and Christie'656 discloses 
destination address screening feature is established for a subscriber to which said calling party 
belongs as set forth above in claim 23. 

Neither Buyukkoc nor Christie'656 explicitly discloses "a group of subscribers" . 
However, Gai teaches a policy server (see FIG. 4, policy server 322) comprising the particular 
policy feature (see FIG. 4, Policy Rule generation engine 414, policy translator 410, and device- 
specific filtering entity; see col. 13, line 61 to col. 14, line 5) including at least one of a 
destination screening feature for a group of subscribers to which the party belongs (see col. 14, 
line 1-15, 56 to col. 15, line 55; applying destination addressing policy rule to a group of users 
(see FIG. 7A, marking users, admin users, executive users, etc.) where a specific user (see FIG. 
7A, John Doe) belongs; see col. see col. 14, line 10-18). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a group of subscribers", as taught by Gai in the combined 
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system of Buyukkoc and Christie '5 65, so that it would ability to allocate network services and 
resources by applying high-level quality of service policies; see Gai col. 5, line 45-55. 

Regarding claims 25, Buyukkoc discloses wherein the ATM network further comprises: 
the policy server to: identify a policy for the called party, the policy for the called party, the 
policy of the called party include address screening feature as set forth above in claim 14. 
Buyukkoc further determine whether a 

wherein the determining whether a policy condition associated with each address 
screening feature is satisfied with respect to signaling message, where, when determining 
whether the policy condition associated with the source address screening feature is satisfied,(see 
FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see 
col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow, Red, and green), associated/related with addressing 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection): the policy server is to 

determining whether an address associated with the calling party (see col. 3, line 5-65; 
see col. 7, line 50 to col. 16, line 65; determining/checking the call/connection of 
user/subscriber), and 

determining that the condition is satisfied for the address validation feature (see col. 3, 
line 5-65; see col. 7, line 50 to col. 16, line 65; determining that status/condition (i.e. green, 
yellow, red) is met/satisfied for the address checking/verification); 

where the connection path is established based on whether the condition is satisfied for 
the source address screening feature (see FIG. 8, step 850, 860, 870; see FIG. 10, steps 1045, 
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1050, 1055; see col. 14, line 1-65; see col. 19, line 35-50; see col. 21, line 40-50; 
setting/establishing the call/connection when conditions/status address checking/verification is 
met/fulfilled). 

Gai discloses disclose a address validation/screening and address screening herein 
where said particular one or more policy features, identified by the policy for the calling party, 
comprises address validation feature and where the determining whether a policy condition 
associated with each policy feature is satisfied comprises: determining whether an address 
associated with the calling party, and determining that the condition is satisfied for the address 
validation feature when the address, associated with the calling party (see FIG. 4- 6, and 7A; see 
col. 9, line 58 to col. 20, line 30). 

Neither Buyukkoc nor Gai explicitly disclose "a second policy server", "within a range 
of authorized addresses ", "when the address, associated with the calling party, is determined to 
be within the range of authorized addresses". 

However, a source address validation/screening is well known in the ATM signaling/SS7. 

In particular, Christie'656 teaches a second policy server (see FIG. 10, second 
call/connection manager (CCM) 1 115/1 120); see col. 20, line 25 to col. 21, line 60) to: a source 
address validation/screening and a destination address screening herein where said particular one 
or more policy features, identified by the policy for the calling party, comprises a source address 
validation feature (see FIG. 7, step 720, 720, 730; policy/rule validation/verification identify the 
caller is the caller (source) and called (destination) addresses/number/IDs validation; see col. 7, 
line 5-55; see col. 15, line 30-60) and 
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determining whether an address associated with the calling party is within a range of 
authorized plurality of addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining 
whether the caller address with within a range of authorized numbers/IDs/ ANIs; note that a 
group or IDs/numbers/addresses/ANIs stored in the access table is within an accessible range), 
and 

determining that the condition is satisfied for the source address validation feature when 
the address, associated with the calling party, is determined to be within the range of authorized 
plurality of addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining the 
status/condition is met/accepted/satisfied for the caller ID/number/addresses/ANI associated with 
the caller is determined to be within range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a second policy server", "within a range of authorized 
plurality of addresses ", "when the address, associated with the calling party, is determined to be 
within the range of authorized plurality of addresses", as taught by Christie'656 in the combined 
system of Buyukkoc and Gai, so that it would can validate the calls and generate a billing record; 
see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claim 26, the combined of Buyukkoc, Gai and Christie'656 discloses source 
address screening feature is established for a subscriber to which said party belongs as set forth 
above in claim 25. 

Neither Buyukkoc nor Christie'656 explicitly discloses "a group of subscribers'" . 
However, Gai teaches a policy server (see FIG. 4, policy server 322) comprising the particular 
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policy feature (see FIG. 4, Policy Rule generation engine 414, policy translator 410, and device- 
specific filtering entity; see col. 13, line 61 to col. 14, line 5) including at least one of a 
destination screening feature for a group of subscribers to which the party belongs (see col. 14, 
line 1-15, 56 to col. 15, line 55; applying destination addressing policy rule to a group of users 
(see FIG. 7A, marking users, admin users, executive users, etc.) where a specific user (see FIG. 
7A, John Doe) belongs; see col. see col. 14, line 10-18). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a group of subscribers" , as taught by Gai in the combined 
system of Buyukkoc and Christie '5 65, so that it would ability to allocate network services and 
resources by applying high-level quality of service policies; see Gai col. 5, line 45-55. 

Regarding claim 46, the combined system of Buyukkoc, Gai and Christie'656 discloses 
all claimed limitations as set forth in claim 19. Buyukkoc discloses accessing said ATM network 
through a particular network port associated with said CPE (see FIG. 9, accessing Switch 922 
through the trunk/port 932; see col. 20, line 1-10). 

Regarding claim 47, Buyukkoc discloses wherein said particular network port is a 
Customer Logical Port (see col. 4, line 20-40; see col. 5, line 20-26; edge node/switch provides 
logical connection/port between customer and the network). Christie'656 also discloses a 
Customer Logical Port (see col. 4, line 35-40; 60-67; a logical/virtual port/link). 

Regarding claim 48, Buyukkoc discloses wherein said particular network port is a full 
physical port (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10). 
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18. Claims 22 and 49 are rejected under 35 U.S. C. 103(a) as being unpatentable over 
Buyukkoc in view of Gai and Smith and further in view of Farris (US006 154445 A). 

Regarding claim 22, Buyukkoc discloses the number of setup messages (see FIG. 8, 
steps 820,830; a message which contains a new call requesting for a route is the SETUP/adding 
party message in ATM signaling/SS7; see col. 19, line 19-31; see col. 20, line 46-52; see col. 20, 
line 39-45; see col. 21, line 19-25). Buyukkoc discloses the number of setup messages as 
described above in claim 18. 

Buyukkoc discloses wherein where said particular one or more policy features, identified 
by the policy for the calling party comprises a call feature (see col. 10, line 50-55; see col. 18, 
line 26-45; call/connection type feature) and where the determining whether a policy condition 
associated with each policy feature is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 
1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; 
determines/decides whether rule/policy condition/state (e.g. yellow, Red, and green), 
associated/related with connectively information, threshold, quality of service, capacity, or status 
of loading/congestion, identified/recognized by the rule/policy associated with a call/connection 
for the user/subscriber is met/fulfilled according to a new call/connection (i.e. 
load/congestion/priority /bandwidth/routes/quality-of-service states/conditions), comprises: 

determining whether the signaling message result for a customer logical port with which 
the calling party is associated (determine/checking if a requested/demand class of service based 
is not-block (i.e. permitted) for a ATM virtual link with VPI port number on a new call; see col. 
14, line 1 to col. 18, line 66; see col. 19, line 10-55); and 
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determining that the condition is satisfied for the call feature when the requested the 
signaling message does not result for the customer logical port with which the calling party is 
associated (determining/checking the condition/status (i.e. red/green/yellow) is met/satisfied for 
type of call when the requested/demand call type is not-blocked (i.e. permitted) for a VPI port 
number on a new party; see col. 14, line 1 to col. 18, line 66; see col. 19, line 10-55). 

Gai also discloses call feature (see col. 3, line 5-60; class/type of service 
selection/choosing) and where the determining whether a policy condition associated with each 
policy feature is satisfied (see FIG. 4, determining if a policy condition/status related/associated 
with each policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises: 

determining call type feature based on the signaling message (determining/calculating a 
request call type based on request/demand; col. 3, line 5-65; see col. 5, line 5-45; see col. 11, line 
1 to col. 12, line 40), 

determining whether the requested call type feature is permitted for a customer logical 
port with which the calling party is associated (determining/calculating if the requested/demand 
call type allowed/permitted for a customer/user logical port/connection (i.e. ATM) with which 
the caller/subscriber is associated/related; col. 3, line 5-65; see col. 5, line 5-45; see col. 11, line 
1 to col. 12, line 40); and 

determining that the condition is satisfied for the call type feature when the requested call 
type feature does not result for the customer logical port with which the calling party is 
associated (determining/checking if the condition/status for traffic is permitted/allow for the 



Application/Control Number: 09/766,943 Page 65 

Art Unit: 2463 

logic port with which the called/user is related; see col. 3, line 5-65; see col. 5, line 5-45; see col. 
11, line 1 to col. 12, line 40). 

Neither Buyukkoc, Smith nor Gai explicitly disclose "a maximum call attempt rate limit." 

However, having a maximum call attempt rate limit/threshold is well known in the 
signaling/SS7. In particular, Farris teaches a maximum call attempt rate limit (see col. 14, line 1- 
12; see col. 11, line 5-17; acceptable/maximum specified rate of call attempts). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "acceptable/maximum specified rate of call attempts", as 
taught by Farris in the combined system of Buyukkoc, Smith and Gai, so that it would can detect 
the predetermined events and/or imminence of predetermined events, and then blocking or 
controlling those events from their incipiency; see Farris col. 14, line 1-6. 

Regarding claim 49, the combined system of Buyukkoc, Gai, Smith and Farris discloses 
all claimed limitation as set forth in claim 22. Buyukkoc discloses the number of setup messages 
(see FIG. 8, steps 820,830; a message which contains a new call requesting for a route is the 
SETUP/adding party message in ATM signaling/SS7; see col. 19, line 19-31; see col. 20, line 
46-52; see col. 20, line 39-45; see col. 21, line 19-25). 

19. Claims 38, and 65 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Gai, Smith and Basso (US006633539B1). 

Regarding claim 38, Buyukkoc discloses a policy feature comprise a maximum call 
limit feature for specifying the total number of calls allowed concurrently with respect to a 
network port used by said party (see col. 14, line 10 to col. 15, line 50; see FIG. 9, trunk/port 
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932; see col. 20, line 1-10; acceptable/allowable total number of calls threshold/limit for a 
trunk/port). Buyukkoc discloses one ore more policy features, identified by the policy for the 
calling party, comprises an maximum call limit feature (see col. 17, line 30-40; see col. 13, line 
45-47; see col. 14, line 15-65; acceptable/maximum call load/limit/bandwidth) and 

wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow, Red, and green), associated/related with connectively information, 
threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 

determining whether maximum call limit, if a call is established between the calling party 
and called party, exceeds a requested bandwidth (see FIG. 8, step 840; see FIG. 10, steps 1035, 
1040; see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table 
VII, VIII; determining/calculating call load/limit/bandwidth is higher/exceed the 
requested/required maximum/acceptable load/limit/bandwidth), and 

determining that the condition is satisfied for the maximum call limit feature when the 
call does not exceed maximum call of calls (see col. 14, line 10-7 to col. 18, line 45; see col. 19, 
line 25- to see col. 21, line 30; Table VII, VIII; determining that the condition/status (i.e. 
red/yellow) for the acceptable/maximum call load/limit/bandwidth when the call is not 
higher/exceed the accepted/maximum calls). 
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Gai also discloses maximum call limit feature (see col. 4, line 50 to col. 5, line 20; 
combined bandwidth processing) and wherein the determining whether a policy condition 
associated with each policy feature is satisfied (see FIG. 4, determining if a policy 
condition/status related/associated with each policy/rule feature identified/recognized by the 
policy/rule for the caller/user is accepted/satisfied; see col. 13, line 60 and col. 18, line 65) 
comprises: determining whether maximum call limit, if a call is established between the calling 
party and called party, exceeds a requested bandwidth determining that the condition is satisfied 
for the maximum call limit feature when the call does not exceed maximum call of calls (see col. 
4, line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65). 

Neither Buyukkoc, Smith nor Gai explicitly disclose "concurrent" . 

However, ATM network having a maximum concurrent call limit/threshed for call 
admission control (CAC) is well known in the art. In particular, Basso teaches a maximum 
concurrent call limit feature (see col. 4, line 25-35; maximum allowed/limit number of 
concurrent connection/call). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "concurrent" , as taught by Basso in the combined system of 
Buyukkoc, Smith and Gai, so that it would control concurrent connections/calls to provide 
efficient protection against signaling congestion; see Basso col. 2, line 35-45. 

Regarding claim 65, the combined system of Buyukkoc, Gai and Basso discloses all 
claimed limitation as set forth in claim 38 above. 
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20. Claims 27-29 and 54-56 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc, Gai and Smith, in view of Kobayashi (US 5,896,371). 

Regarding claims 27, Buyukkoc discloses wherein where said particular one or more 
policy features, identified by the policy for the calling party, comprises a maximum size limit 
(see col. 14, line 15-65; acceptable/maximum load/size/bandwidth before the call are blocked) 
and where the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow, Red, and green), associated/related with connectively information, 
threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 

determining whether a size in the signaling message exceeds a limit (see col. 14, line 10- 
7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; determining/checking if the 
acceptable size/load/capacity in the new call exceed threshold) , and 

determining that the condition is satisfied for the maximum size limit feature when the 
size does not exceed the limit (see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- to see 
col. 21, line 30; determining the condition/status (e.g. red, yellow, green) is met/satisfied for the 
acceptable/maximum load/size/bandwidth when it does not exceed threshold). 

Gai also discloses wherein where said particular one or more policy features, identified 
by the policy for the calling party, comprises a maximum size limit and where the determining 
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whether a policy condition associated with each policy feature is satisfied comprises: 
determining whether a burst size in the signaling message exceeds a limit, and determining that 
the condition is satisfied for the maximum burst size limit feature when the burst size does not 
exceed the limit (see FIG. 4- 6, and 7A; see col. 9, line 58 to col. 20, line 30). 

Neither Buyukkoc, Smith nor Gai explicitly disclose "burst-sized request". 

However, limiting a burst-size request is well known in the art of ATM. In particular, 
Kobayashi teaches a maximum burst size limit feature for limiting a burst-size request associated 
with said call (see FIG. 6; see col. 12, line 55 to col. 13, line 35; a limiting/setting/changing the 
number of cells transmitted in each call). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "burst-sized request", as taught by Kobayashi in the 
combined system of Buyukkoc, Smith and Gai, so that it would provide a flow control performed 
cooperatively by the network and the terminal equipment and call accepted control is simplified; 
see Kobayashi col. 7, line 46-52; col. 8, line 40-45. 

Regarding claim 28, the combined system of Buyukkoc, Gai, Smith and Kobayashi 
discloses all claimed limitations. Kobayashi discloses the number of packets per second allowed 
to be transmitted to said ATM network with respect to said call (see FIG. 6; see col. 12, line 55 
to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to transmit in each call 
to ATM network). Therefore, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to provide the number of packets per second requested to be 
transmitted, as taught by Kobayashi in the combined system of Buyukkoc, Smith and Gai, for the 
same motivation as above in claim 27. 
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Regarding claim 29, the combined system of Buyukkoc, Gai , Smith and Kobayashi 
discloses all claimed limitations. Kobayashi discloses the number of packets per second allowed 
to be received by said party from said ATM network with respect to said call (see FIG. 6; see 
col. 12, line 55 to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to 
received in each call from ATM network). Therefore, it would have been obvious to one having 
ordinary skill in the art at the time the invention was made to provide the number of packets per 
second requested to be received, as taught by Kobayashi in the combined system of Buyukkoc, 
Smith, Gai, for the same motivation as above in claim 27. 

Regarding claim 54, the combined system of Buyukkoc, Gai , Smith and Kobayashi 
discloses all claimed limitations as set forth in claim 27 above. 

Regarding claim 55, Kobayashi discloses the number of packets per second allowed to 
be transmitted to said ATM network with respect to said call (see FIG. 6; see col. 12, line 55 to 
col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to transmit in each call to 
ATM network). Therefore, it would have been obvious to one having ordinary skill in the art at 
the time the invention was made to provide the number of packets per second requested to be 
transmitted, as taught by Kobayashi in the combined system of Buyukkoc, Gai and Smith, for the 
same motivation as above in claim 27. 

Regarding claim 56, Kobayashi discloses the number of packets per second allowed to 
be received by said party from said ATM network with respect to said call (see FIG. 6; see col. 
12, line 55 to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to received in 
each call from ATM network). Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to provide the number of packets per second 
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requested to be received, as taught by Kobayashi in the combined system of Buyukkoc, Gai and 
Smith, for the same motivation as above in claim 27. 

21 . Claims 32-37 and 59-64 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Gai, Smith and Kilkki (US006041039A). 

Regarding claims 32-37, the combined system of Buyukkoc, Gai and Smith discloses 
service class as described above in claim 31 and 58. Buyukkoc further discloses constant bit rate 
service (CBR) and variable bit rate service (VBR) (see col. 1, line 50-60). 

Neither Buyukkoc, Gai nor Smith explicitly discloses, "real-time VBR service, non-real 
time VBR, unspecified bit-rate (UBR), and available bit-rate (ABR) ". 

However, the ATM class of services a real-time VBR service, non-real time VBR, 
unspecified bit-rate (UBR), and available bit-rate (ABR) is well known in ATM standard. In 
particular, Kilkki teaches CBR, VBR, a real-time VBR service, non-real time VBR, unspecified 
bit-rate (UBR), and available bit-rate (ABR) (see col. 1, line 54-67). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide quality of service class defined by ATM standard, as taught 
by Kilkki in the combined system of Buyukkoc, Gai and Smith, so that it would provide a 
capability to manage increases in network load, supporting both real-time and non-real time 
application, and offering, in certain circumstances, a guaranteed level service quality; see Kilkki 
col. 1, line 44-53, also by using the ATM standard services, it will enable the service provider to 
interoperate between multi-vendor networks. 
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Regarding claims 59-64, the combined system of Buyukkoc, Gai and Smith discloses all 
claimed limitations as set forth in claims 32-37 above. 

22. Claim 44 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai, and further in view of Noake (US006751222B1). 

Regarding claim 44, neither Buyukkoc nor Gai explicitly disclose a release message. 
However, a release message is well know in the ATM signaling/SS7 in order to disconnect the 
call. In particular, Noake teaches a release message (see FIG. 4, RELEASE message; see col. 8, 
line 9-39). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to provide a release message, as taught by Noake in the combined 
system of Buyukkoc and Gai, so that it would make effective use of a band and the respective 
apparatus by transmitting connection information, and by sending/receiving a release message it 
will notify to stop the cell assembling and disassembling processes; see Noake col. 2, line 55-64; 
col. 8, line 19-24. 

Conclusion 

23 . THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
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will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 
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